1. Field of the Invention
The present invention relates to a data transfer scheme for carrying out data transfer at a data transfer device on behalf of another device.
2. Description of the Related Art
The client-server type information system formed by servers for providing various services through a network and clients for requesting desired services to the servers has been widely used. In particular, the World Wide Web system (which is also simply called Web) formed by Web servers and clients that communicate with each other by using the HTTP protocol on the Internet is the very widely used client-server type information system. Usually, a server program is operating on a server and a prescribed tool (program) such as a browser is operating on a client. The contents of the services provided on the Internet are also wide ranging so that there are various existing services including services for providing, delivering or transferring information such as that of text, still image, video and audio (home pages, e-mails, and digital contents, for example) or programs, electronic shop services for selling goods, reservation services for seats, rooms, etc., agency services for various contracts, etc., and services in new styles are appearing steadily.
Now in the client-server type information system such as the Web, the service is provided basically by carrying out data transfer between the client and the server, regardless of the style of the service to be provided. Consequently, a capacity (bandwidth) of the network to be used for communications between the client and the server tends to be a bottleneck of the entire system. For this reason, usually, the caching technique has been used in order to reduce the network load.
In the case of the Web system, the browser or the like that is operating on the client often uses a cache mechanism for caching recently accessed data. In the Web, accesses are made by specifying information or services by using names called URLs, so that among data that are returned in response to information or services requested to the Web servers in the past, those data that are cachable are recorded in the cache on the client in correspondence with their URLs. In this case, when an information or service with the same URL as that recorded in the cache is requested, if it is possible to judge that the response data recorded in the cache has not become obsolete, it is possible to eliminate a communication between the client and the Web server by returning that response data recorded in the cache.
When a plurality of users are existing on a LAN inside offices of an enterprise, a LAN of a research organization or a LAN inside a home, it is popular to provide a proxy server between that LAN and the Internet and provide the cache mechanism in the proxy server. The cache inside the client (the cache of the browser, for example) will be operated as a dedicated cache of that client or user, but the cache of the proxy server on the LAN will be operated as a cache shared by users of the plurality of clients. For this reason, the cache of the proxy server works efficiently even in the case of making an access to the URL accessed by another client in the past.
Now, in the Web, communications between the client and the server are carried out by the protocol called HTTP. The HTTP protocol uses a set of a “request message” to be sent from the client to the server and a “response message” to be returned from the server to the client in response to that request.
The request message is formed by a “request header” and a “request body”. The request header contains various information necessary for the access such as a URL for specifying an information or service to be accessed and a method name indicating the type of access. The request body contains data to be sent to the server. Such data contained in the request body are also referred to as “request data”.
The major methods for the request message that are used for accesses of information or services include a “GET method” that reads out an information on the server, a “PUT method” that writes data of the user into the server, and a “POST method” that receives a processing result from the server in response to the request. Besides them, methods such as a “DELETE method” are also defined.
In many cases, the request body of the request message in the GET method and the response body of the response message in the PUT method are empty. The request body or the request message in the POST method contains information to be used for the processing on the server side if necessary, and the response body of the response message in the POST method contains data obtained as a result of the processing of the server.
The data to be read out from the server by the GET method can be classified into “dynamic data” that are to be generated at the server side at a time or each request and “static data” that are to be returned by just reading the stored data in the server. The dynamic data can possibly have different contents at different occasions of reading even for the same URL, so that in many cases, the server returns the response message with the response header that includes an indication that it is not cachable. Consequently, what are to be the caching targets among the Web data are the static data.
These static data can be classified into “shared data” that can be accessed by unspecified many users and “private data” that allowed accesses only to the specific user by the user authentication. The former shared data are cachable for any caches. However, the latter private data are not cachable for a shared cache such as that of the proxy server (because there is a need for the server to return the private data after the user authentication). The private data are cachable in the case of a personal dedicated cache such as that of the browser.
In the POST method, the server returns the result by the response message with the response header that includes an indication that it is not cachable in general. For this reason, the response data of the POST method are usually not the caching target.
In the PUT method, data are to be sent to the server so that there is no processing that involves the cache.
On the other band, the response message is formed by a “response header” and a “response body”. The response header contains a status code indicating a processing result and various headers for notifying information associated with it, and the response body contains the requested information or data of the processing result of the requested service. Such data contained in the response body are also referred to as “response data”.
The status code of the response header comprises three digits number. The meaning of the status code is different for each numerical value, and can be largely classified into five classes according to the numerical value of the first one digit.
The class of the first digit “1” is a class used in the situation where the processing corresponding to the request is still continuing. For example, the status code “100” indicates that the processing is in progress, and after receiving this status code, the browser have to wait until the further response comes from the server.
The class of the first digit “2” is a class that generally indicates success. For example, When an access to data located at the URL specified by the GET method is accepted, the server transmits a response message formed by the response header that contains the status code “200” and the response body that contains the data corresponding to the URL, to the client. Also, when the storing of the data into the URL specified by the PUT method succeeds, the response message with the response header containing the status code “201” is transmitted to the client.
The class of the first digit “3” is a class that indicates the re-direction. When the server returns the status code belonging to this class in response to the request of the client, it implies that “some further action at the client side is necessary in order to fulfill the purpose for which this request was transmitted”.
For example, when the services normally provided on that server cannot be provided temporarily due to some trouble of the server machine, the other server is often employed to provide these services as substitution, and in such a case, the server in trouble can return the response with the status code “302” indicating that “what is requested is temporarily provided at another location” and a Location header containing the URL of a location at which the services are provided as substitution, in response to the request from the client. When the response containing the status code “302” is received, the client can have the desired service provided by referring to the URL written in the Location header described above and transmitting the request again with respect to the server corresponding to that URL.
Also, there are many Web browsers which have the cache function as mentioned above, and when such a Web browser having the cache function transmits the GET request again with respect to the URL for which the data is already cached, the time at which the data of this URL was received previously is attached to the request as an associated information. This implies that the server is requested in such a manner as “please transmit the data only when the data corresponding to the URL has been updated after that time”. Such a method is generally called re-validation, and the server can return the status code “304” to the browser in response to the validation request from the browser, when the data corresponding to the URL has not been updated after the specified time. This is the status code that implies “please use the local copy”, and when this response is received, the browser takes out the cached data again and utilize it as the data obtained as a result of the GET request.
The class of the first digit “4” is a class that indicates the occurrence of some error due to the client side. For example, when the client program with a bug transmits the request that is not in accordance with the HTTP specification, the server returns the status code “400”, in order to notify that the request is not in accordance with the HTTP specification. Also, when the request with respect to the non-existing URL is transmitted due to a typographical error by the user, the server returns the status code “404”, in order to notify that the specified URL does not exist.
The class of the first digit “5” is a class that indicates the occurrence of some error due to the server side. For example, when the server falls into the situation where the services cannot be provided temporarily due to some trouble of the server machine and it is impossible to provide another machine for providing the services as a substitution, the server returns the status code “503” in response to the request from the client, in order to notify that it is in the situation where the service cannot be provided temporarily.
In the conventional Web cache, the caching targets are the static contents. Many information or services on the Web were disclosed to unspecified many users and the information was updated not frequently, so that the rate of the static contents were very high and therefore even the conventional caching technique was effective in reducing the network load.
However, in conjunction with the spread of a system in which the user makes accesses to the information or services on the server through the network by using the Web browser such as that of Web based ASP (Application Service Provider), the amount of data that cannot be handled by the conventional caching technique is increasing. For example;                there are many private data for which the accessible users are limited by the user authentication;        there are many dynamic data to be generated by referring to the back-end database;        there are many cases of using the POST method such as those of the accounting slip processing and the searching; and        there are many cases of using the PUT method for the purpose of sharing information within a group.        
As a consequence, the use of the conventional caching technique alone has been becoming rather ineffective as a method for reducing the network load.